2 9 2004 g 



PATENT 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
In re the application of: 



Group Art Unit: 2131 



KINSELLA et al. 
Serial No.: 10/661,619 
Filed: September 15, 2003 

For: AUTHORISATION OF ONLINE TRANSACTIONS 

CLAIM TO PRIORITY 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

The benefit of the filing date of the prior foreign application 
filed in the following foreign country is hereby requested and the right 
of priority provided in 35 U.S.C. §119 is hereby claimed: 

European Patent Application No. EP01650028.2 filed 16 March 2001. 

In support of this claim, filed herewith is a certified copy of said 
foreign application. 

Respectfully submitted, 
JACOBSON HOLMAN PLLC 



400 Seventh Street, N.W. 
Washington, D.C. 20004-2201 
Telephone: (202) 638-6666 

Atty. Docket No.: P69138US0 
Date: March 29, 2004 
JCH:crj 




/0 



Europaisches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



Bescheinigung Certificate 



Attestation 



Die angehefteten Unter la- 
gen stimmen mit der 
ursprunglich eingereichten 
Fassung der auf dem nach- 
sten Blatt bezeichneten 
europaischen Patentanmel- 
dung uberein. 



The attached documents Les documents fixes a 
are exact copies of the cette attestation sont 
European patent application conformes a la version 
described on the following initialement deposee de 
page, as originally filed. la demande de brevet 

europeen specif iee a la 
page suivante. 



Patentanmeldung Nr. Patent application No. Demande de brevet n° 

01650028.2 



Der Prasident des Europaischen Patentamts: 
Im Auftrag 

For the President of the European Patent Office 

Le President de I'Office europeen des brevets 
P-o. 



R C van Dijk 



DEN HAAG , DEN 
THE HAGUE, 
LA HAYE,LE 



05/03/02 



EPA/EPO/OEB Form 1014 - 02.91 



1 



Europaisches European Office europeen 

Patentamt Patent Office des brevets 



Blatt 2 der Bescheinigung 
Sheet 2 of the certificate 
Page 2 de ('attestation 



Anmeldung Nr.: 
Application no.: 
Demande n*: 



01650028.2 



Anmelder: 

Applicant(s): 

Demandeur(s): 

Fabrlx Investments Limited 

Dublin 12 

IRELAND 



Anmeldetag: 
Date of filing: 
Date de depot: 



16/03/01 



Bezeichnung der Erfindung: 
Title of the invention: 
Titre de I'invention: 

Authentication of online transactions 



. In Anspruch genommene Priori at (en) / Priority(ies) claimed / Priorite(s) revendiquee(s) 

Staat: Tag: Aktenzeichen: 

State: Date: File no. 

Pays: Date: Numero de depot: 



Internationale Pate ntklassifikat ion: 
International Patent classification: 
Classification internationale des brevets: 

G07F7/10, G07F7/08 



Am Anmeldetag benannte Vert rag staaten: 

Contracting states designated at date of filing: AT/BE/CH/CY/DE/DK/ES/FI/FR/GB/GR/IE/IT/LI/LU/MC/NL/PT/SE/TR 
Etats contractants designes lors du depot: 

Bemerkungen: 
Remarks: 
Re marques: 



EPA/EPO/OEB Form 1012 -11.00 



- 1 - 



"Authorisation of online transactions" 

Introduction 

5 The invention relates to online transaction processing such as online banking, 
particularly for corporate customers. 

At present, development of use of automated transaction processing is being limited 
by the lack of structures for effective authorisation of transactions where the 
1 0 customer is an organisation with a number of users. 

The invention addresses this problem. 

Statements of Invention 

15 

According to the invention, there is provided a system for performing on-line 
transactions, the system comprising means for authorising a transaction for a user of 
a customer having a plurality of users as follows:- 

20 receiving a request for a proposed transaction; and 

determining if the proposed transaction falls within the domain of an 
authorisation model, and if so, authorising the transaction only when a set of 
signatories within the customer organisation as defined by the authorisation 
25 model have approved it. 

In one embodiment, the authorisation means comprises means for allowing an 
administration user of the customer to define the model in on-line communication 
with the system. 

30 



In another embodiment, the authorisation model comprises rules and the system 
comprises a rule engine comprises means for enforcing the rules. 

In a further embodiment, a rule comprises a transaction condition associated with an 
authority state of approval users. 

In one embodiment, the transaction condition comprises values for financial amount, 
transaction type, and account variables. 

In another embodiment, the authority state comprises a collection of authority 
groups of approval users. 

In a further embodiment, the authority group in turn comprises a collection of 
authority sets of approval users. 

In one embodiment, the system comprises means for passing the transaction to a 
back office system for funds authorisation after transaction authorisation. 

In another embodiment, the authorisation means comprises means for allowing an 
administration user to dynamically modify the authorisation model. 

In one embodiment, the system comprises means for downloading instructions for a 
design wizard to guide said user through a rule definition process. 

Detailed Description of the Invention 

The invention will be more clearly understood from the following description of 
some embodiments thereof, given by way of example only with reference to the 
accompanying drawings in which:- 
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Fig. 1 is a schematic representation of how an authorisation rule is generated; 

Fig. 2 is a flow diagram illustrating various transactions related to 
authorisation; 

5 

Figs. 3 and 4 are flow diagrams for steps for definition of an authorisation 
rule; 

Fig. 5 is a diagram illustrating system components involved in definition of an 
10 authorisation rule, and Figs. 6 to 10 are screen shots illustrating creation of 

rules. 

Referring to Fig. 1, at its simplest an authorisation model governs authorisation of 
transactions within a corporate customer organisation. Authorisation rules are 
15 developed by matching of transaction conditions with authority states. The 
transaction condition variables are amount, type, and account: 

Amount is a currency defined numerical field that allows bands of authorisation 
rules to be created. 

20 Type is an enumerated list allowing different authorisation schemas to be used 
for different banking services. 

Account is a customer-specific list of accounts allowing tighter or looser rules to 
be imposed on specific accounts. 

25 An authority state is a collection of authority groups, each of which is a collection of 
authority sets. An authority set is a collection of named individuals or department 
rank types defining what level of authorisation is required. 
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The state-group-set structure allows the authorisation administrator a fine grained 
level of control and combines this with the ease of administration of grouping sets 
together, to allow the simple addition of new rules; or new members within existing 
sets. This coupling of fine granularity control with coarse granularity of 
administration provides an easily-administrated and flexible system. 

Finally, an authorisation rule is a specific association between a transaction 
condition and an authority state. 

Referring to Fig. 2, the service provider is an online bank using a system called 
"Bankworld". When a user logs in the bank system determines if there are any 
transactions pending, and if so notifies the user. When a transaction is requested, the 
system determines if it is limited by the authorisation model. If not, it is posted to 
the back office which will perform funds authorisation (a check that funds for the 
proposed transaction are available). If it is limited by the model, (i.e. its 
characteristics match those limited by the model) then necessary signatories must be 
sought before posting to the back office. 

Each customer has a user who is an authorisation administrator. The setting of an 
authorisation rule is performed by the administrator without the need for any 
involvement of bank staff. When an administrative request is made, the bank system 
firsdy checks that the user is an administrator. An authorisation administrator is 
identified by being flagged as such by an administration tool. The flag is detected by 
a presentation layer. 

If verification is positive, the system loads floating signatory groups and transaction 
conditions from a database. A rule design wizard then guides the administrator 
through a process for setting a rule. A rule database is then updated. 
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As shown in Fig. 3, the first step in this process is to define a transaction condition 
and associate it with an authority. The next step is to define the authority state. This 
involves defining a group of people who must sign approval for a signatory set. The 
example of Figs. 3 and 4 is relatively simple, for illustrative purposes. The following 
is the logic of the rule which is defined. 



IF THE TRANSACTION COMPLIES WITH 

FT<500 [Transfer of less than 1R£500 from ALL ACCOUN TS on Funds 
1 0 Transfer) 

THEN TRANSACTION IS SUCCESSFULLY SIGNED IF AUTHORITY STATE 
Senior Authority IS TRUE 
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I HE S TATE Senior Authority IS TRUE IF ANY OF THE FOLLOWING SIGNATORY 
SET(S) ARE TRUE: 

SIGNA TORY SET: Sicnatorvl 

f 

20 IS TRUE IF SIGNED BY THE FOLLOWING GROUPS(S) : 

Managers 
I 

CONSISTING OF 2 OF RANK Level 2 FROM ANY OF 

DEPARTMENT(S) 
25 [ 

Depll 
— OR — 
Dept2 

1 

30 1 

1 

The display screens illustrate the rule being developed in a manner as shown in Figs. 
3 and 4. 

35 

Referring to Fig. 5, the authorisation design wizard is downloaded to the customer's 
Web client. On the server side there is a transaction type filter, an account list filter, 
and a localisation component. An authorisation rule engine manages definition of a 
rule and an authorisation data manager captures the data for rule definition. A 
40 database has floating transaction conditions and floating signatory states. A back- 
office sub-system stores account data and transaction programs. 
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Each user of BankWorld is assigned a set of user roles which configures their access 
to the system. A role either explicitly allows a service to be offered, explicitly 
disallows a service to be offered, or cares not whether a service is offered. The list of 
5 transactions a user is allowed access to is only those which have been explicitly 
allowed by a role they hold and which have not been explicitly disallowed by any 
other role they hold; this is the transaction filter. 

A customer is the legal owner of a set of accounts and a user is a customer defined 
1 0 operator on a subset of those accounts. The account filter shows only accounts that a 
user has been allowed access rights to, less any accounts which are included from 
transactions on the basis that the department they belong to does not allow outgoing 
transactions to be made. This is the account filter. 



15 BankWorld is an international product that holds within its database translations of 
all BankWorld generated text and this text can be retranslated by a customer into 
other languages. Each BankWorld user identifies a locale they wish to view 

--information, in and Jhis locale .describes the language and from then on all 

BankWorld messages to that user will be offered in the default language of the locale 

20 of their choice. 



Account filters and transaction filters can be controlled by a bank administrator using 
the user administration tools. The choice of locale can be controlled by the user and 
the list of locales can be controlled by the bank through the system administration 
25 tools. 



Regarding the authorisation rule engine, this is an executor that enforces the rules 
defined by the authorisation administration tool. On receipt of each transaction it 
tests the characteristics of the user-submitted transaction against the list of registered 
30 authorisation rules. If a characteristic identifies the transaction as being subject to 
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the registered rule, the authorisation rule engine determines the number of required 
signatures, retrieves from the database the set of signatures already associated with 
the transaction, and tests that the authorisation rule has been met. If the rule has 
been met, the transaction is posted to the back office for authorisation. If there is a 
5 signature deficiency the transaction is marked as pending, the new signature is 
stored, and prospective signatories are notified. If the transaction characteristics do 
not cause an authorisation rule to be triggered, the transaction is posted to the back 
office for funds authorisation. 

10 Referring to Figs. 6 to 10, a new transaction condition can be created in a simple 
manner using drop-down lists as shown in Fig. 6, and a new authority state can be 
created as shown in Figs. 7 and 8. This involves specifying who is required to sign 
approval for each state. Authorisation (signatory) groups and sets may be created as 
shown in Figs. 9 and 10. 

15 

The following is an example case study to illustrate the invention. 

WebWideBank - Internet Enabled financial institution using BankWorld as its 
Internet Channel 

20 ClientsRus - Customer of WebWideBank that holds the following accounts 

• DepositA - Demand Notice Savings Account (Used for Capital 
Expenditure) 

• CurrentB - Current Account (Used for Day-to-day Expenditure) 

• CurrentC - Current Account (Used for Marketing Expenses) 
25 Alice - ClientsRus authorisation administrator 

Bob - ClientsRus user who is ClientsRus IT Manager 
Carol - ClientsRus user who is a ClientsRus IT Support Executive 
Dave - ClientsRus user who is a ClientsRus Accountant 
Edward - ClientsRus user who is a ClientsRus Sales Manager 
30 Fiona - ClientsRus user who is a ClientsRus Director 



Gerard - ClientsRus user who is a ClientsRus Sales Executive 
Harriet - ClientsRus user who is a ClientsRus Director 

Scenario 

ClientsRus is a large corporate whose auditors have raised concerns about their 
purchase order mechanism. Their auditor's main concern was that although a PO 
system was in place it was more often ignored, and that ClientsRus had no 
mechanism in place that allowed the system to be enforced. 

Happily for ClientsRus, their bankers WebWideBank have recently upgraded their 
Internet channel to use BankWorld that allows an automated PO system to be 
enforced on electronic transactions. ClientsRus signs up for this service, and the 
company secretary nominates Alice for the role of Authorization Administrator. 

Alice, on login to the web interface is presented with a Java design tool that 
allows her to create the PO rules as directed by the auditors. The rules created by 

L Overseas Remittances for any amount from any account must be 
authorised by a ClientsRus Director 

2. Domestic Transfers for any amount from any account must be authorised 
by a ClientsRus Manager 

3. All transfers from DepositA for any amount must be authorised by Dave 
(the ClientsRus Accountant) 

4. All transfers from any account for amounts greater than IEP 5000 must be 
authorised by Dave and a ClientsRus Director 

5. All transfers from CurrentC must be approved by a member of the Sales 
Team 

6. All transfers from CurrentC over IEP 2000 must be authorised by the 
Sales Manager 
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Carol is asked by her manager Bob to order a new colour laser printer costing 
USD 3000, and as it is capital expenditure to charge it to the DepositA 
accountant. The printer overseas vendor requires payment in full prior to 
5 delivery, so Carol logs onto the web to process the payment. 

The exchange rate between USD and IEP when Carol inputs the payment is 1 USD 
= 0.66 IEP, so the transaction is for IEP 2000. Carol submits the payment for 
processing. The transaction conditions are checked, and the authorization rules 
1 0 triggered are 

• 1 as the payment is an overseas remittance 

• 3 as the payment is from the DepositA account 

Carol is informed that she has insufficient authorisation to process this 
15 transaction, and Dave, Fiona and Harriet are all notified on their next login that 

there is a transaction pending their authorization. 

Harriet logs in before Fiona and authorises the payment, and sends a- mail 
message to Dave, reminding him how important this colour printer is for the 
20 company and asking him to expedite the matter. Dave then digitally signs the 

transaction. When Fiona logs in, the pending transaction notification has been 
removed, as once Harriet signed the transaction, rule 1 was satisfied. 

Once Dave signed the transaction it was submitted to the back office for 
25 processing; if there was insufficient funds in the account the transaction may still 

be rejected, but the ClientsRus PO system has now been implemented to their 
auditors' approval. 

It will be appreciated that the invention allows the following advantages for the 
30 customer 
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1. Commercial customers can manage the authorization level of each user at a 
local level in a flexible manner. 

2. Commercial customers can set the conditions for each payment based on an 
infinite number of permutations. 

3. Banks can provide an automated authorization system that can accommodate 
all existing flexibility in the manual process. 

4. Because the method allows the banks and customers to use an automated 
process, transaction costs are reduced for both parties. 

5. The process logs all changes in the conditions set and thus can be audited by 
the audit sections of both the bank and the customer. 

6. Banks can be guaranteed that all transactions are processed by the authorized 
persons in the company. 



The invention is not limited to the embodiments described but may be varied i 
construction and detail. 
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Claims 

1. A system for performing on-line transactions, the system comprising means 
for authorising a transaction for a user of a customer having a plurality of 
users as follows:- 

receiving a request for a proposed transaction; and 

determining if the proposed transaction falls within the domain of an 
authorisation model, and if so, authorising the transaction only when a set of 
signatories within the customer organisation as defined by the authorisation 
model have approved it. 

2. A system as claimed in claim 1, wherein the authorisation means comprises 
means for allowing an administration user of the customer to define the 
model in on-line communication with the system. 

3. A system as claimed in claims 1 or 2, wherein the , authorisation, models 
comprises rules and the system comprises a rule engine comprises means for 
enforcing the rules. 

4. A system as claimed in claim 3, wherein a rule comprises a transaction 
condition associated with an authority state of approval users. 

5. A system as claimed in claim 4, wherein the transaction condition comprises 
values for financial amount, transaction type, and account variables. 

6. A system as claimed in claims 4 or 5, wherein the authority state comprises a 
collection of authority groups of approval users. 
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A system as claimed in claim 6, wherein the authority group in turn 
comprises a collection of authority sets of approval users. 

A system as claimed in any preceding claim, comprising means for passing 
the transaction to a back office system for funds authorisation after 
transaction authorisation. 

A system as claimed in any preceding claim, wherein the authorisation means 
comprises means for allowing an administration user to dynamically modify 
the authorisation model. 

A system as claimed in claim 9, wherein the system comprises means for 
downloading instructions for a design wizard to guide said user through a rule 
definition process. 

A computer program product comprising software code for completing a 
system as claimed in any preceding claim when executing on a digital 
computer. , , .... 
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ABSTRACT 

"Authorisation of online transactions" 

5 A service provider on-line bank has a rule engine which maintains an authorisation 
model. The model is developed and maintained by an administration user of a 
customer. The model rules each associate a transaction condition with an authority 
state. The authority state comprises authority groups, in turn comprising authority 
sets of approval users. For a transaction to be authorised, all approval users must 
10 sign approval and the proposed transaction must comply with the transaction 
condition. 
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